Design by Contract (“DBC”) enables software developers to produce, at minimal extra cost, software that is inherently more reliable than would otherwise be constructed. The basis of design-by-contract/program-by-contract is the specification of obligation in terms of the service, the servant (the entity offering the service) and the service consumer. The obligations of the service consumer are defined by preconditions; the obligations of the service itself are defined by post-conditions; and the obligations of the servant are defined by the class invariants. DBC was first introduced in Meyer, B., “Object Oriented Software Construction”, Prentice-Hall Publishers: 1988, which is hereby incorporated by reference in its entirety.
Components within component based software contain the implementation of functionality that corresponds to one or more given contracts. In general, the vast majority of implementation languages do not provide any direct support for the concept of design-by-contract/program-by-contract. Furthermore, even if an implementation language does provide direct support for program-by-contract, this support is of a static nature, that is, support for pre-conditions, post-conditions and invariants (“PP&I”) specified during the development cycle.
Within a large scale distributed system, only the most simplistic of PP&I are identifiable during the development cycle. The more detailed PP&I that are required to ensure a robust and reliable system are often dependent on business drivers and system constraints that are simply not predictable during development. For example, the amount of bandwidth that must be available in order to initiate a particular type of multimedia stream is based on guarantees made to the customer by the service provider, which in turn is dependent on the plan chosen by the customer. This is the quintessential example of detailed PP&I that cannot be predicted by engineers or system administrators in a static fashion.
This leaves the operator of any given large scale distributed system (such as the operator of a traditional information communication or telecommunications, or ICT, network) balancing a system that is not easily extended due to the limited flexibility and reliability of the software supporting a feature-oriented service model. There is tremendous interest within the ICT community in moving to a component based model that enables the deployment of flexible and general services that are then composed through an orchestration mechanism to provide the services and products being demanded by network subscribers. Current solutions in this space still suffer from massive integration efforts that result in a substantial delay to the deployment of new services and applications; where the service provider/network operator wants to roll out services in days or weeks, the current systems still require months, or in some extreme cases, years.
Therefore a need exists to overcome the problems discussed above.